I personally don't think this is a strong force. IMHO, voluntariness pertains more to the development of and making contributions to OSS, not necessarily to using it.

Could any of you two (@gruetter @NewMexicoKid) suggest any possible commit suggestion to modify this or resolve this discussion?

Might this be a problem for a dedicated pattern/donut? I feel this is not so much related to OSS trumping InnerSource.

You meant that this one could go to it's own pattern instead, right?

Different Business Lines (BLs) are selecting different SW components to do the same function, resulting in inconsistencies in the user experience.

Will leave this thread open but I think it should not prevent us from merging this PR.

This comment doesn't have to be addressed right now, but in the log run it would be nice if our patterns had consistent terminology (glossary) for terms like these (Business Lines).

An additional effect possibly worth mentioning is that this will also result in more effort for procurement and supplier management.

I've referenced @rrrutledge point into #170.

I've seen @gruetter and @NewMexicoKid agreeing on the possible need to mention the procurement and supplier management point. Can any of you two create a commit suggestion or a commit around this?

Keeping this comment open, to make it easier to find this comment after the PR is merged.

This line seems like part-Context (Internally developed components should have advantages over competing open source) and part-Solution (If you can clearly demonstrate this, it can be persuasive.) rather than Forces.

@rrrutledge how about: Internally developed components can be made more robust and better suited towards corporate needs. Reasons for preferring inner source over open source alternatives might include issues with the open source license, use of proprietary and/or patented components, and functional/competitive advantages. The more that such internal components are used within a company, the better the ROI for the inner source development efforts. On the other hand, open source advances can sometimes leap frog internal development and without periodic assessment, it can be difficult to know when to stop investment in inner source development and switch to the adoption of open source components.

I cannot tell if this thread has been worked into the latest version of the pattern already. Will leave the tread open.

It's unclear to me what these two last bullet points are trying to get at or how they are uniquely appropriate to describing this pattern?

I have the same problem.

I think the point of this force is that it can be difficult to fight perception among dispersed and silo'd engineering staff and to communicate (1) that the inner source project exits, (2) that it has advantages over competing open source, (3) that there are legitimate reasons for preferring the inner source over competing open source software.

If I understand the diagram (and this article) right, then it looks like the diagram suggests that it is preferable to use an inner source project over an open source project in areas of software that are differentiating to the company's core business?

Yes

What do you think about the following:

• Add this .jpg to the repo maybe in /assets/ or something similar such that it can be rendered with the pattern? Also, who created the image and are there possibly any copyrights attached to it that we need to take into account?
• Should there be some phrasing adding the insight from the image into the text?

The "owner" of the picture in gDrive is @NewMexicoKid and it was created 11.10.2016, 18:33.
Not sure if that helps us to figure out where it originally came frame?

I also did a google image search for the picture and parts of the text, but could find anything.

I found the original source for this image. Yay :)
https://www.semanticscholar.org/paper/Commodification-of-Industrial-Software%3A-A-Case-for-Linden-Lundell/54d6cb77a86e292ff1845eb910c1a1f258e6cee3

A lot of these suggested resolutions are (gut-feel) very large undertakings and outside the realm of reasonableness to just go and do. I agree that they would help the situation your describing, but feel that they are large to the point of their not having practical utility in including them here as independent items. Perhaps some of them need to be their own pattern and linked to from here? Or perhaps the need to include such large items as a solution indicates that the problem space that this pattern is trying to address is too broad?

@rrrutledge : Are you ok with merging with the current state of the resolution section (there has been a slight rework), or do you think further rework is needed before merging?

While I agree that the Solutions section is asking for a lot right now, I suggest that we just leave this as is and get the pattern published as Initial. That will make it easier for others to find, read, and improve this pattern in the future if anybody has actually found a working solution for this problem. (right now we don't have a Known Instance yet, so this isn't a proven solution yet)

An additional effect possibly worth mentioning is that this will also result in more effort for procurement and supplier management.

I have the same problem.

@rrrutledge : Are you ok with merging with the current state of the resolution section (there has been a slight rework), or do you think further rework is needed before merging?

Could any of you two (@gruetter @NewMexicoKid) suggest any possible commit suggestion to modify this or resolve this discussion?

What do you think about the following:

• Add this .jpg to the repo maybe in /assets/ or something similar such that it can be rendered with the pattern? Also, who created the image and are there possibly any copyrights attached to it that we need to take into account?
• Should there be some phrasing adding the insight from the image into the text?

I've referenced @rrrutledge point into #170.

I've seen @gruetter and @NewMexicoKid agreeing on the possible need to mention the procurement and supplier management point. Can any of you two create a commit suggestion or a commit around this?